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The Orion Crew Module (CM) is NASA’s next generation manned space vehicle, 
scheduled to return humans to lunar orbit in the coming decade. The Orion avionics and 
GN&C architectures have progressed through a number of project phases and are nearing 
completion of a major milestone. The first unmanned test mission, dubbed “Exploration 
Flight Test One” (EFT-1) is scheduled to launch from NASA Kennedy Space Center late 
next year and provides the first integrated test of all the vehicle systems, avionics and 
software. 


Nomenclature 


ARINC 

= Aeronautical Radio, Incorporated 

LEO 

= Low Earth Orbit 

CCR 

= Cross Channel Restart 

PDU 

= Power and Data Unit 

CM 

= Crew Module 

OIMU 

= Orion Inertial Measurement Unit 

EFT-1 

= Exploration Flight Test One 

ODN 

= Orion Data Network 

El 

= Entry Interface 

RPM 

= Reset Protected Memory 

EKE 

= Extended Kalman Filter 

SECO 

= Secondary Engine Cuttoff 

ELV 

= Expendable Launch Vehicle 

SCR 

= Self Checking Pair 

FCM 

= Flight Control Module 

SDR 

= Stored Data Restart 

FDIR 

= Fault Detection, Isolation and Recovery 

SEU 

= Single Event Upset 

FILTNAV 

= Filtered Navigator 

SLDB 

= Separately Loadable Database 

GCI 

= GN&C Command Interface 

SM 

= Service Module 

GN&C 

= Guidance Navigation and Control 

TM 

= Timeline Manager 

GPS 

= Global Positioning System 

VPU 

= Video Processing Unit 

HWIL 

= Hardware in the Loop 

UPP 

= User Parameter Processor 

ICRF 

ITRF 

= International Celestial Reference Frame 
= International Terrestrial Reference Frame 

VL 

= Virtual Link 


I. Introduction 

T HE Orion Crew Module (CM) is NASA’s next generation manned space vehicle, scheduled to return humans to 
lunar orbit in the coming decade. The Orion avionics and Guidance Navigation and Control (GN&C) 
architectures have progressed through a number of project phases and are nearing completion of a major milestone. 
The first unmanned test mission, dubbed “Exploration Flight Test One” (EFT-1) is scheduled to launch from NASA 
Kennedy Space Center late next year and provides the first integrated test of all the vehicle systems, avionics and 
software. 

The EFT-1 mission will be an unmanned test flight that includes a high speed re-entry from an elliptical orbit, 
which will be launched on an expendable launch vehicle (ELV). Figure 1 shows the ground track and altitude 
profile of the 4 hour and 10 minute mission. The ELV will place CM and the ELV upper stage into a low Earth 
orbit (LEO) for one revolution. After the first LEO, the ELV upper stage will re-ignite and place the combined 
upper stage/CM into an elliptical orbit whose perigee results in a high energy entry to test CM response in a 
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relatively high velocity, high heating environment. The trajectory was chosen to provide higher stresses on the 
thermal protection and guided entry systems, as compared against a lower energy LEO entry. However the required 
entry geometry together with constraints on inclination and landing location result in a trajectory that lingers for 
many hours in the Van Allen radiation belts (Figure 2). This exposes the vehicle and avionics to much higher levels 
of high energy proton radiation for far longer than a typical low Earth Orbit or lunar transit trajectory would 
encounter. As a result, Van Allen radiation exceeds the design environment for the Orion avionics system, and 
poses a significant risk to the Flight Control Module (FCM) computers that house the GN&C flight software. 



Figure 1. EFT-1 Groundtack and Altitude Profiles. 
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Figure 2. EFT-1 Trajectory and Van Allen Radiation Exposure 


The measures taken by the Orion GN&C, Flight Software and Avionics teams to mitigate the risks associated 
with the Van Allen radiation on EFT-1 are covered in the paper. Background is provided on the radiation 
environment and the Orion avionics, as well as an overview of the GN&C software architecture. The measures 
taken to handle radiation induced failure of the one or both of the FCM’s are presented, and finally simulation and 
actual hardware-in-the-loop (HWIL) results are shown confirming the validity of the implementation. 


A. Radiation Environment 

Figure 3 shows the EFT- 1 altitude profile with the proton flux encountered during the flight. While there are two 
periods of exposure to Van Allen proton radiation, most of the robustness requirements are driven by the second, 
descending passage through the belts during which high levels of flux persist for more than 20 minutes. During this 
period, a single event upset (SEU) of one or both of the FCM’s has high enough probability to justify the mitigation 
steps described below. 
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Figure 3. Radiation Flux and Orion Altitude Profile 


II. Avionics and Flight Software Overview 


A. Avionics 

Figure 4 is a simplified diagram of the Orion avionics. GN&C sensors include two Orion Inertial Measurement 
Units (OIMU’s), a Vision Processing Unit (VPU) to process camera images, three barometric altimeters housed 
together and a single Global Positioning (GPS) receiver. All of the sensors communicate to one of two Power and 
Data Units (PDU’s). The PDU’s multiplex analog and serial data from the sensors and write the data to the Orion 
Data Network (ODN). The OIMU’s write their data directly as messages to the ODN, but they are routed through 
PDU network switches as shown. 

Sensor data are passed via the ODN to the GN&C software application within one of two Flight Control 
Modules (FCM’s). Each FCM contains a self-checking pair (SCP) of processors mounted on a single card, each 
with its own memory. The SCPs run identical applications and provide protection against incorrect outputs caused 
by radiation-induced upsets or other processor problems. When an FCM detects a mis-compare between the two 
SCP processors, the FCM ceases outputting commands to the ODN. The OIMUs and PDUs have a priority logic 
which accepts commands from FCM1 unless FCM1 commands are unavailable, in which case, commands from 
FCM2 are processed. This process allows for automated redundancy for an FCM failure. Table 1 summarizes the 
Orion avionics components of interest. 


3 

American Institute of Aeronautics and Astronautics 


GN&C Sensors 


Power Data Units 


Thruster 
String A 



Orton Data Network (ODN) 
Analog Signals 
Serial Signals (R5422) 


Figure 4. Orion Avionics Diagram 


Table 1. Orion Avionics Components 


Component 

Description 1 

Orion Inertial Measurement Unit 
(01 MU) 

•Senses vehicle body rates 
•Senses vehicle acceleration 

Global Positioning System Receiver 
(GPSR) 

•Receives GPS satellite RF signals 

•Generates pseudorange and deltarange measurements for 
each satellite 

•Performs Receiver Autonomous Integrity Monitoring (RAIM) 
algorithms 

Barometric Altimeter 
(BALT) 

•Senses static pressure at the capsule outer shell 

Video Processing Unit (VPU) 

•Performs onboard video processing and telemetry downlink 
•Performs backup attitude propagation 
•Houses backup cross channel restart software 

Power and Data Unit 
(PDU) 

•Supplies onboard network schedule for ODN 

•Supplies power for avionics units 

•Supplies commands to RC$ thruster units 

•RS422 serial data communication from GPSR onto the ODN 

Flight Control Module (FCM) 

•Primary Time management software 
•Primary Vehicle Timeline management software 
•Primary Command and Data Handling software 
•Primary Guidance, Navigation and Control software 


Should a single FCM failure occur, it is often desirable to restart the failed FCM and restore redundancy, so the 
ODN and FCM software provide a cross-channel data stream to initialize critical states in the failed FCM from the 
running FCM. This means that the GN&C applications resident in the FCMs must have the capability to provide 
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and accept initialization data from its counterpart FCM. The process of starting one FCM from the other is referred 
to as a “Cross Channel Restart” (CCR) and will be detailed in subsequent sections. 

Since the EFT-1 mission’s second pass through the Van Allen belts has significant duration, Orion is also 
required to protect for dual FCM failures occurring simultaneously, or nearly simultaneously. Automated protection 
for dual FCM failures is provided by storing attitude and translation navigation data and using the stored data to re- 
initialize the GN&C applications. The translation state data are time-tagged and kept static in non-volatile memory 
during the restart process. However, because Orion has no external attitude sensor for EFT-1, attitude data must be 
propagated with IMU gyro inputs during the time that the FCMs are inoperative to maintain attitude knowledge. For 
this reason, attitude propagation software is embedded on a processor in the VPU. The attitude state is continuously 
updated by the FCMs until a dual FCM failure event. At that point, the VPU continues to propagate attitude until 
the FCM’s are restarted from stored data. This process of re-starting the both FCM’s from stored data is called a 
“Stored Data Restart” (SDR) and will also be described in subsequent sections. 



Figure 5. Orion Dual Flight Control Module (FCM) Partition Architecture 


III. GN&C Software Architecture 

The Orion GN&C software is implemented in the FCMs as an Aeronautical Radio, Incorporated (ARINC) 653 
Time-space Partition [reference for ARINC OS]. The GN&C partition consists of and executive framework that 
houses algorithms which are autocoded from MATLAB/Simulink. 

The navigation portion of the software (Figure 4) includes two channels, each of which is associated with one of 
the OIMUs. Each channel has an extended Kalman Filter (EKF) that executes at 1 Hz, and provides GPS 
measurement updates to the filtered navigation (FILTNAV) module, which propagates the state based on OIMU 
data between measurements. Each channel also houses a pure inertial propagator (Inertial Nav) that provides an 
inertial-only backup solution to protect for corruption of the state by a faulty GPS. Note that each channel has an 
independent IMU, but both channels receive measurements from the single GPS on the EFT-1 vehicle. 
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Figure 6. Diagram of GN&C Navigation Dual Channel Software Architecture 


Downstream of the dual channels, navigation fault detection, isolation and recovery (Nav FDIR) software selects 
the state for use by guidance and control from the filtered (GPS aided FILTNAV state) or the inertial state from 
channel one or channel 2. The selected inertially referenced state is sent to the user parameter processor (UPP) for 
processing to generate required navigation data for downstream customers. UPP outputs include Earth fixed states, 
flight data parameters such as angle of attack, bank and sideslip as well as filtered angular rates and accelerations. 


B. Inflight Restarts: Overview of Cross Channel Restart (CCR) & Stored Data Restart (SDR) 

When radiation upset event conditions are detected by the self-checking pair FCM hardware (or if one is 
intentionally commanded by ground operators), this triggers a restart of the affected FCM hardware while the rest of 
the avionics continue to operate. In the event that the non-restarting FCM is operating and uninhibited it continues 
to fly the vehicle closed loop without interruption. However for EFT-1 there is also a real, although low probability 
chance that the secondary FCM may not be operational at the time of the restart. This constitutes what is referred to 
as a dual FCM restart and was deemed to be significant enough of a risk to the program to develop a solution in 
software. In the dual restart case a combination of data stored in non-volatile FCM memory and auxiliary VPU 
hardware is used to provide enough critical data to restart the FCM(s) without an active counterpart. In either restart 
case, all of the critical GN&C flight software states and data must be transferred to the restarting FCM and utilized 
in the application software to initialize all the algorithms at the appropriate point in the mission event sequence. The 
paper presents a high level overview of the embedded restart logic on each FCM for determining upon restart or 
power up whether one of the restart cases is encountered or if the vehicle is proceeding through a nominal power up 
on the launch pad. 

C. GN&C Software 

The GN&C software executes on one of the many software partitions allocated on each FCM. This paper 
presents an overview of the EFT-1 GN&C software architecture with a heavy focus on navigation, as most of the 
complexity in performing inflight restarts deals with restarting the navigation software. The timing and rate 
monotonic scheduling scheme is summarized to provide background for the sections that discuss how the multi-rate 
navigation system is re-anchored to the current Orion time during the restart process. 

The Orion GN&C software architecture includes a GN&C command interface (GCI) that provides moding 
commands and configuration data to navigation, guidance and control domain modules. Automated sequences are 
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enacted within GCI by sequencing through data configurable activities loaded onto the vehicle via Separately 
Loadable Databases (SLDBs). Each activity consists of the appropriate mode commands and configuration data 
needed to accomplish the activity objective. GCI also contains software to perform automated transitions between 
activities based on data configurable transition criteria. The vehicle “Timeline Manager (TM)” is responsible for 
coordinating event transitions across all vehicle subsystems including GN&C, and the interface for communicating 
changes across all subsystems is through “mission segments”. Within the GN&C subsystem, GCI responds to a new 
mission segment by kicking off a new sequence of activities. Transitions between mission segments within the TM 
software are often based on state data and flags provided by GN&C. While all of the GN&C state data cannot be 
synchronized between the FCMs, transitions between the high level segments are synchronized to ensure that 
segment boundaries could never occur at slightly different times within each FCM. This critical event 
synchronization is accomplished by including the transition status of the counterpart FCM in the segment transition 
criteria. The paper describes the critical state data exchanged between TM and GCI counterpart instances in order to 
ensure that vehicle configuration parameters, sequencing information as well as command data are preserved during 
a restart. 

The navigation software is divided in to two “channels” associated with each of the redundant Orion IMUs. 
Each channel includes both filtered and inertial solutions. The filtered solutions incorporate GPS measurements 
within a 1 Hz Extended Kalman Filter (EKF) that interacts with a 40 Hz inertial propagator. In addition a separate, 
inertial solution is maintained on the vehicle for each navigation channel to provide a backup for the filtered 
navigation solution taking measurements from the Orion GPS receiver which has never been flown in an exo- 
atmospheric environment. The paper discusses the mechanisms for initializing both the filtered and inertial states 
during a restart as well as the navigation trades used to identify and prioritize the subset of navigation filter states 
that passed between FCMs. Additionally other non-navigation algorithms also require cross channel initialization, 
including fault detection, isolation and recovery (FDIR) and entry guidance algorithms. Finally, after describing the 
software architecture and necessary navigation features required to support single and dual FCM restarts, the effect 
on the navigation system performance is quantified. 

IV. Restart Solutions GN&C Flight Software 

AUTHOR’S NOTE (TO BE REMOVED): In the previous sections we establish the Avionics architecture and 
FCM partition architecture, as well as the GN&C FSW Architecture and the concept of Inflight CCR and SDR 
restarts. We also want to establish enough background in the Navigation architecture to discuss multiple 
Navigation channels, filtered vs. Inertial solutions, etc. Here we elaborate into the specific implementation for the 
GN&C partition and show performance plots for the navigation filters. 

The EFT-1 Orion mission is largely meant to be a test flight that will prove out many avionics and software 
designs such that much of the vehicle design can be considered validated for subsequent lunar missions and beyond. 
However, certain aspects of the EFT-1 design will not be carried forward into later missions due to the nature of the 
design. It is important to recognize the restart architecture for EFT-1 is one of the areas that will very likely evolve 
into a very different scheme for later missions. The trajectories and time spent lingering in high radiation 
environments will be drastically different for subsequent missions as most all trajectories departing from LEO punch 
through the Van Allen radiation belts comparatively quickly. In addition, the planned addition of a third redundant 
FCM will add to the overall robustness of the avionics. The Navigation system will be upgraded to include star 
trackers, sun sensors and optical navigation technologies that will aid in the acquisition of and maintenance of 
critical states during flight. As such the design of the inflight CCR and SDR approaches will likely only be 
necessary for EFT-1, although certain components and methodologies may apply in the future. However, it is 
nonetheless critical to the program that the vehicle is protected for radiation induced upset events as it was deemed 
to be a significant risk to the success of the mission. 

Figure 7 depicts the region of the EFT-1 trajectory over which the vehicle software is required to support 
automated inflight restarts. Most notably, this region encompasses the entire period over which the heaviest Van 
Allen radiation will be experienced, including the period in which the CM separates from the Service Module (SM) 
and translation maneuver sequences are initiated. This event is referred to as CM/SM separation (the SM is inert for 
this mission and remains attached to the launch vehicle). After Orion descends to an altitude of 500 nmi (five 
minutes prior to entry interface), inflight restarts are not supported and an FCM failure after that point would result 
in the vehicle returning on the secondary redundant FCM. Ground operations also has a contingency command 
available to restart an FCM if needed outside these regions. 
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Figure 7. Exploration Flight Test-1 Inflight Restart Protection Region 


The following sections detail the most important aspects of the inflight restart design as it pertains to the GN&C 
partition, followed by results that demonstrate the expected performance for the EFT-1 mission through analysis and 
Monte Carlo results. 


A. FCM Partition Cross Channel Data 

The overall design philosophy for restart of the GN&C partition follows from the partition restart guidelines 1 . 
Each FCM partition, as detailed in Figure 5, establishes one or more virtual link (VL) cross channel data messages 
with the required data needed to reinitialize the partitions at a restart epoch. Bandwidth considerations were a factor 
in this design, as there are limitations in the quantity of data that could be exchanged over the ODN network on a 
given execution cycle. Fortunately for the EFT-1 design thus far there has been enough bandwidth available to fit 
all inter-partition cross channel data within these constraints. Just prior to the beginning of each 1Hz cycle, each 
partition issues their cross channel data messages over the ODN such that their counterpart could make use of this 
data during a restart event. Once an FCM restart is initiated, it is expected to be completed in 9-15 seconds allowing 
time for the core kernel software and data loads to be instantiated and loaded into memory. Then upon restarting 
each partition first checks to determine if counterpart cross channel data messages are available prior to falling into 
the default case that initializes the software sitting on the ground at the launch site. 

An important aspect of the FCM design is that the partition cross channel data messages are stored in inter 
partition reset protected memory (RPM), which is depicted in Figure 5 as a shared memory area on each FCM. The 
RPM data area is used to support the Stored Data Reset (SDR) case when a counterpart FCM is unavailable to 
provide restart data because data written to RPM persists across reset events, provided that the FCM continues to 
remain powered over the commanded reset. This is a critical aspect of the SDR case, as RPM can be used in lieu of 


Considerable effort was also expended to ensure that a simulation environment could populate cross channel data 
using the same methods to restart one or more FCMs at various points along the mission profile in order to facilitate 
testing requirements. 
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any other cross channel data message to restart an FCM. More details on this restart method will be provided on 
SDR in subsection D. 

For the GN&C partition especially, some specialized considerations were also required for restart to function 
properly. GN&C algorithms require additional inputs that are not captured in the GN&C cross channel data 
messages. These data include 1) the Timeline Management phase, segment and mission sequencing information as 
well as 2) the Command and Data Handling Orion Time broadcast. These items allow the GN&C partition to know 
what in part of the mission sequence a restart is taking place as well as the current Orion Time required to process 
IMU messages off of the ODN. Both of these items are obtained by allowing the GN&C partition to subscribe to 
the TVM and partition cross channel data (AKA “cross strapped” partitions), at some expense to the complexity of 
the restart process. Some consideration was given to the option of including these data items within GN&C partition 
cross channel data, however this was ruled out for the EFT-1 design. 


B. GN&C Cross Channel Data 

The GN&C partition requires several areas of data exchange to support the inflight restart capabilities discussed 
in the subsequent sections. This cross channel data represents all of the critical GN&C states that are required to 
initialize GN&C partition while in orbit in the EFT-1 mission in the regions depicted in Figure 7. The state areas 
and examples of each are discussed in turn are broadly characterized into four areas as follows: 

1) Sequencing and command data 

2) Fault Detection, Isolation and Recovery (FDIR) 

3) Guidance and Control 

4) Navigation 

Sequencing cross channel data is comprised of all states that tell the GN&C partition where the vehicle is 
within the mission sequence such as the current GN&C Activity 2 and the Activity elapsed time. This critical state 
data informs the GN&C partition what parameter configurations to load for each operating CSU at that point in the 
mission. All GN&C command data is exchanged as part of the cross channel data message to inform the restarting 
partition about any changes that may have been issued by the ground to override default states that exist in memory. 
For example, the ground could potentially issue a contingency command to override the default landing site target 
(latitude, longitude) and without passing this knowledge between FCMs this command would need to be reissued to 
the FCM after each restart event. The EFT-1 mission has only a handful of commands that may be issued by the 
ground in a contingency scenario, as such this list of cross channel parameters is relatively small. For subsequent 
missions with many more potential commands and crew interactions this approach will likely not be feasible, 
however there will also likely be a fail-safe and writable file system onboard which will mitigate much of the need 
for this capability. 

FDIR cross channel data includes all parameters that are necessary to those algorithms such as hardware failure 
states, persistence counters and other key parameters necessary to determine the health of GN&C related sensors 
during the mission. This set of state data does not comprise a lot of bandwidth in bytes, but without this key 
knowledge the restarting application would not have critical knowledge about which sensors are failed or suspect. 
Exchanging this type of state information mitigates for the highly undesirable case that a navigation channel is 
selected differently on a restarting FCM than its counterpart. 

Guidance and Control algorithms actually do not require any cross channel data exchange for the EFT-1 
mission. Control and pointing algorithms are mostly dependent on the Navigation states and inputs directly from the 
IMU and as a result do not require much in terms of restart states. Initially there was some concern that a control 
algorithm could require knowledge of the thruster firing states in order to meet minimum jet on-time requirements, 
however this concern was abated through analysis 3 . For EFT-1 all of the Guidance algorithms are not active during 
the period of restart susceptibility shown in Figure 7, although things such as the guided landing target are included 
for reasons described above. 

The Navigation state data comprises the bulk of the GN&C cross channel data required for EFT-1, as such this 
data will be described more comprehensively. Applicable reference frames for navigation state information include 
the International Celestial Reference Frame (ICRF) - an Earth centered inertial frame, and the International 
Terrestrial Reference Frame (ITRF), an Earth centered, Earth fixed frame. As described earlier in Section II and 
depicted in Figure 6, the Navigation system maintains four independent solutions for position, velocity and attitude 
quaternions all of which must be transferred to the restarting FCM to maintain the integrity of the system. In 
addition, the two instantiations of the EKF maintain 2 x 26 = 52 filter states corresponding to the GPS clock bias 
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(be) and drift (dc) states, accelerometer and gyro biases, scale factors, misalignments, etc. for each navigation 
channel. The filter states, X, may be expressed as 4 


X = [ r ICRF T v ICRF T qT h c d c Pi p 2 - P 24 ] T 

where the components of X represent the inertial position (r ICRF ), inertial velocity ( v ICRF ), attitude Euler axis rotation 
vector ($, clock bias (b c ) and clock drift ( d c ). The remaining state parameters (pi-24) represent Markov states that 
corresponding to the estimated IMU error states which are optimized in the filter implementation to take advantage 
of matrix sparseness using an efficient UDU formulation 5 . 

Finally and very importantly, the EKF also requires knowledge of the uncertainty for each of the filter states, 
commonly expressed in the form of a state covariance matrix, (P 35x35). The elements of the covariance may be 
expressed as a function of Gaussian standard deviation values (cr^) and correlation coefficients (pij) as 


puj = 



V t = 7 

V i * j. 


\pu\ ^ 1 


Besides exceeding the cross channel bandwidth limitations, it is inefficient and unnecessary to transfer the entire 
P covariance matrix to the restarting FCM because P is symmetric. To limit the amount of data required to restart 
the navigation filters, the covariance matrix data is down selected to include the entire diagonal of 35 state variance 
values (o'”), as well as the 36 correlation coefficients (p* ; -) corresponding to the upper 9x9 position, velocity and 
attitude state correlations, for each navigation channel. All of the correlations between the clock bias, clock drift 
and IMU error states (p^) are dropped for the purposes of inflight restarts as this information is assumed to be 
negligible for the purposes of restarting the filters for the EFT-1 mission. Of primary concern in this exchange are 
the cross correlation terms relating the attitude to position and velocity states, as there is no external source for 
attitude information for EFT-1 and those state correlations allow the coupled attitude-translation EKF to make 
corrections to the attitude state in a GPS measurement rich environment. 6 It is worth noting that although the clock 
bias (b c ) and drift (b d ) states are available in cross channel data, these initial values are derived from the GPSR 
estimates as the GPSR hardware is not affected by a restarting FCM. Bias and drift variances (g£ c , a^ d ) are obtained 
from either the GPSR hardware or parameter (SLDB) loads as opposed to cross channel data. 

Considerable effort was expended in determining how to represent and make use of the cross channel 
covariance data in the restarting EKF. In addition, the Navigation team debated the merits and pitfalls of inflating 
the values of P in the restarting filter to account for unmodeled disturbance forces to prevent a situation where the 
filter became too ‘smug’, thereby rejecting otherwise valid measurements and allowing position and velocity. The 
counterpoint concern that was raised in inflating the values was related to difficulties in the case that multiple FCM 
restarts were encountered on the mission. In fact, it is somewhat likely that multiple FCM resets will be encountered 
on EFT-1. Ultimately it was decided that the best compromise was to leave the EKF covariance values unsealed 
during a restart event, but instead represent the cross channel covariance terms in the UVW coordinate frame where 
they would be less likely to change substantially over any reasonable restart interval. These concerns are mostly 
related to the performance during a stored data reset where there will be some period of time in which neither FCM 
is computing a navigation solution. These are assumptions which must be validated through analysis and test over 
the next year leading up to the EFT-1 mission. 

The navigation solutions for any recursive filter are naturally sensitive to initial conditions during an inflight 
restart. Although all the critical navigation states are passed between FCMs, there are enough parameters missing 
and differences with respect to measurement processing to guarantee that a restarting FCM and its counterpart will 
produce slightly different solutions after a cross channel or stored data restart occurs. If no other failures are 
present, neither FCM will be any more correct than the other, however this feature of the design does lead to more 
complexity in the analysis of the system stability and failure modes, particularly during the entry phase of flight. In 
scenarios where FCMs are not completely in sync numerically, the overall closed loop system response is chaotic in 
nature, much like the well-known ‘butterfly effect’. Slightly different navigation solutions between FCMs can easily 
lead to slightly different control thruster firing patterns, which in turn raises questions about how to deal with a 
flight control module that is attempting to control the vehicle, but in reality whose outputs are never reaching the 
effectors. This is particularly true for onboard fault detection algorithms and pyro sequencing algorithms that may 
rely on the past thruster firing history to perform their functions. These topics will not be addressed in much greater 
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detail for this paper in lieu of more details and results on the nuances of and approach for ensuring navigation 
robustness for EFT-1. 

One of the key takeaways from the development of the EFT-1 cross channel restart and inflight restart capability 
is that GN&C algorithms must be designed at the onset with inflight restarts in mind. Whenever persistent states are 
used in an algorithm developers must be trained to ask themselves whether those individual states are critical to the 
overall success of the mission and if so, how those states should be initialized in the event of an inflight restart. It 
can be very costly and invasive to develop initialization and synching routines into the system as an afterthought to 
the GN&C algorithm design process. Secondly, it is very helpful for developers to have design and implementation 
standards (AKA “design patterns”) in place to provide examples and to assist in the design of restart functionality, 
such that all GN&C algorithms cohere into an overall picture when restarts are taking place. Otherwise many 
similar approaches for the same functionality are invented and communication of the design may become more 
complicated and error prone. 


C. Restart Capabilities and Testing 

Inflight restart performance for the GN&C subsystem is assessed with the aid of closed loop Monte Carlo 
simulations of the overall system performance with variations in all of the key system driving parameters such as 
GPS constellation and firmware errors, IMU error sources, RCS thruster performance and latencies, mass properties 
and atmospheric effects. With current limitations of the simulation environment available only a single FCM may 
be simulated at a given time, however this limitation can be overcome to effectively analyze and bound restart 
performance through the following restart procedure: 

1) Identify key simulation restart epochs of interest where CCR and SDR are to be analyzed. These points 
should initially be selected to bound some of the possible worst case scenarios in which restarts may occur. 

2) Run end-to-end Monte Carlo simulations of the entire mission profile, recording key restart data and error 
statistics at the key restart epochs. 

3) Restart the simulation and FSW using the CCR/SDR restart functionality at the epochs of interest, 
accounting for the appropriate navigation and truth state dispersions at that particular restart point. 

While not as elegant as fully simulating restarts with dual FCMs running, the above procedure does permit the 
overall restart performance and functionality to be assessed. Future development of the simulation architecture may 
enable restarts to be fully dispersed as would be performed for any other Monte Carlo input parameter. The goal for 
this type of analysis is to stress the system beyond what might be reasonably expected in even the worst case 
scenarios to see what type of system robustness can be achieved. However it is acknowledged that this type of 
analysis would not capture the effects seen from multiple (repeated) resets in different configurations. This type of 
analysis will be the subject of later technical studies. For the EFT-1 trajectory several restart epochs were analyzed 
for CCR and SDR performance as depicted in red text in Figure 8: 

• The SEC02 Restart Epoch is setup to initialize the FSW just following the second large bum and shutdown 
of the main engines in FEO, roughly 121 minutes after launch. At this point in the trajectory many GPS 
measurements are available allowing for rapid convergence of the Navigation solution, however inertial 
velocities and tme anomaly rates are also at a maximum for the mission. Restart conditions after the SEC02 
epoch were simulated to demonstrate resilience during the first spike in radiation susceptibility as well because 
it will be a driver for some of the worst case stored data restart cases. The duration for these mns are 10 
minutes (600 seconds) to ensure adequate convergence of the GPS solution after a restart event. 

• The CM/SM Separation Restart Epoch initializes the FSW just after the CM/SM separation event roughly 
206 minutes after launch, which is a bounding case from a number of perspectives. First, the number of GPS 
measurements at this altitude tends to be very sparse at this point in the trajectory and a number of constellation 
geometries produce less than the minimum number of 5 SVs required to produce a valid and RAIM evaluated 
solution. Secondly, while the inertial velocities and true anomaly rates are relatively low at this point in the 
trajectory, the CM/SM separation maneuver does impart delta- V and body rates onto the CM which can add to 
the restart effects. The cases starting at CM/SM separation are run for roughly 42 minutes (2500 seconds) well 
past the 500 nautical mile threshold to ensure that GPS has reconverged prior to entry interface. 

• The Entry Interface Restart Epoch initializes the FSW just prior to the designated entry interface altitude 
of -68 nautical mile (400,000 ft) threshold to examine the effect of performing inflight restarts at the latest 
possible seconds prior to losing GPS in measurement blackout. Notice that this restart epoch is roughly 5 
minutes after the last Van Allen radiation effects are expected, and entry velocities are very high at this point. 
Indeed, this would be one of the worst possible moments to experience single or dual FCM resets. So if some 
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level of robustness can be achieved even at this point this should provide some measure of confidence that the 
system will hold together at earlier points in the trajectory. All entry cases are 



Figure 8. Exploration Flight Test-1 Inflight Restart Epochs of Interest 


All of the subsequent analysis test cases shown make use of these three restart epochs as they bound some of the 
worst possible points in the trajectory for which inflight restarts may take place. While it is certainly possible that 
additional anomalies could crop up by performing restarts at other epochs in the mission or by repeating multiple 
resets at various points throughout the trajectory, these bounding cases provide reasonable confidence that the 
system will hold together as intended and the flight software will operate as intended. Figure 8a shows the total 
number of GPS measurements expected as a function of time for a representative EFT-1 trajectory. Note the 
correlation in the number of measurements with altitude and the relative sparseness of available measurements 
around CM/SM separation. 



Elapsed Time [mini 
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Figure 8a. Total Number of GPS Measurements for the EFT-1 Trajectory 


D. Cross Channel Restart Performance 

In this section the CCR restart performance for the navigation system is quantified through a number of Monte 
Carlo simulations beginning at the restart epochs depicted in Figure 8. Each restart epoch is accompanied by sets of 
500 run Monte Carlos with dispersed GPS constellation and firmware errors, IMU error sources and initial condition 
states, which represent the Navigation EKF filter performance at that point in the trajectory. In the following 
performance plots Figures 9 and following, state errors are computed relative to the corresponding truth states for 
the ensemble of cases shown. Each ensemble of errors also includes a mean error, taken at each time step along the 
trajectory. Finally and very importantly, the ±3 a EKF filter covariance values are represented for each component 
as a minimum (best performing) and maximum (worst performing) over the ensemble of Monte Carlo cases. The 
covariance bounds provide an indication of how well the filter’s confidence in its solution aligned with the actual 
errors. If all measurements were completely Gaussian in nature and all error sources complete captured correctly, 
then the filter should produce errors that remain within the ±3 a bounds -99.975 % of the time. 



p«<f Time (i) Etapeed Time [sj 


Figure 9. SEC02 CCR Inflight Restart Navigation (Position, Velocity) Performance 

The SEC02 CCR restart case is depicted in Figure 9, showing good performance. From the restart position and 
velocity plots in Figure 9, it should be noted that the filter 3 a covariance bounds remain more or less constant over 
the course of this run, bounding the errors. This indicates an overall healthy filter and that the initial covariance 
restart bounds are consistent for this restart epoch as the filter continues to process GPS PR and DR measurements. 
Points in the trajectory in which the ensemble of errors (as characterized by the mean error) tend to walk outside of 
the 3 covariance bounds (e.g., Position component Z) are indicative of the EKF performance when attempting to 
process time-correlated PR and DR measurements as zero mean Gaussian random variables. In reality these 
measurement are not Gaussian but contain errors due to Ionosphere and Troposphere effects. These are issues that 
are not due to restarts specifically but endemic of how the measurements are modeled and these must be addressed 
as part of filter tuning. 7 
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Figure 10. CM/SM Separation CCR Inflight Restart Navigation (Position, Velocity) Performance 

Figures 10 and 11 capture the CCR restart performance after the CM/SM separation event through the 500 
nautical mile altitude threshold shown in Figure 9. The CM/SM separation restart epoch takes place near apogee at 
much higher altitude and as a result many fewer GPS satellites are in view. Of those measurements available, it is 
very likely that a large percentage of them will be low elevation SVs which can introduce noticeable errors due to 
Ionospheric and Tropospheric effects. The covariance bounds for the position, velocity and the clock states 
indicate that a subset of the runs are indeed encountering poor satellite geometries as the start of the run, however all 
runs are converged by the end of the run as more satellites become available. Initial tip off rates and delta-v’s 
injected by the CM/SM separation maneuver are sensed and appropriately incorporated into the filter position, 
velocity and attitude states. The attitude profiles for this phase of flight are very well behaved. 


Attitude Error Clock Bias $ Drift Errors 



Figure 11. CM/SM Separation CCR Inflight Restart Navigation (Attitude, Clock Bias and Drift) Performance 


Finally, Figure 12 describes the performance at the Entry Interface restart epoch. Roughly 10-20 seconds of 
GPSR measurement processing are encountered prior to the start of GPS blackout. Measurement blackout lasts 
roughly 150 seconds before GPS is reacquired for the final descent and landing phase. Overall the performance is 
well behaved for an entry case as the position and velocity errors remain well bounded by the covariance values and 
within touchdown requirement bounds. 
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Figure 12. El Entry CCR Inflight Restart Navigation (Position, Velocity) Performance 


E. Stored Data Restart Performance 


Stored Data Restart is conceptually very similar to a Cross Channel Reset with some noticeable differences. 
First and most foremost, since neither FCM will be running for many seconds while the FCMs reboot there will 
inevitably be a gap in IMU and GPS measurement processing over the stored data restart. Position and velocity 
states are less susceptible to being issues for the EFT-1 mission because GPS measurements can be reacquired after 
the restart event. However for EFT-1 Orion has no external source for attitude knowledge and every cycle IMU 
data is not processed attitude errors will grow, potentially leading to a loss of vehicle scenario. As a consequence of 
this for EFT-1 it was determined that a third redundant source for attitude knowledge was required that would be 
capable of bridging the gap over the stored data restart interval. The VPU was selected as the best location to 
perform this function and serve as a pseudo backup computer, due to its relative radiation tolerance and throughput 
loading for the EFT-1 mission. Figure 13 depicts the concept of Stored Data Restart with multiple FCM and VPU 
interactions. At some point in the mission over the time of radiation exposure described in Figure 7, one of the 
FCMs is triggered to reset. It naturally takes the computer some time to reboot, At FC M-> during which the secondary 
FCM also resets. When the first FCM completes its reboot cycle it first looks for a counterpart cross channel 
message. Not seeing one available, it instead looks to the VPU for the same data and can perform a reset based on 
the data from this source instead. The VPU backup software is designed to take attitude and state information from 
either FCM, provided that at least one valid message is received on a given execution cycle. If no valid messages 
are received, the VPU software applies a basic attitude propagation function from the latest samples of 200Hz 
OIMU data. This is accomplished for all four of the Filtered/Inertial, Channel 1/2 attitude states being maintained 
for EFT-1. In addition, the VPU would capture any changes in mission sequencing data if those transitions 
happened to occur after the first FCM went down but prior to the second resetting. Thus, when the FCM completes 
a SDR it is able to receive an up-to-date attitude state as well as the current Orion time tag from the VPU. The 
second FCM that undergoes a reset (FCM 2 in Figure 13) will restart from the active FCM using the CCR method 
described earlier. In the extremely unlikely event that both FCMs undergo resets on exactly the same minor cycle 
then they would both perform a Stored Data Reset from the VPU. 
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Figure 13. Diagram of expected Stored Data Restart (SDR) Timing 


Once the propagated attitude and sequencing states are obtained from the VPU software the primary FCM 
GN&C partition has enough information to restart from Reset Protected Memory as it would in a CCR case with the 
exception of one additional step. The position and velocity translational states must be propagated forward over the 
SDR outage time, At S nR, otherwise very large errors will be introduced when restarting the filters at orbital 
velocities. Some consideration was given to propagating position and velocity from IMU delta-V measurements in 
the VPU as well as attitude. However this was decided to be more complexity than is required for the VPU 
software, at the expense of being unable to account for non-conservative accelerations over the interval At S DR- 
Therefore a simple low order gravitational propagation scheme was built into the GN&C SDR restart logic. This 
scheme propagates all four sets of Filtered/Inertial, Channel 1/2 translational states forward to the appropriate epoch 
after a SDR event. This propagation scheme accounts for J2 effects, but any higher order effects or non- 
conservative accelerations are neglected for EFT-1. This simple propagation scheme will introduce errors into the 
navigation states after SDR events, but fortunately these errors can be explicitly quantified in advance. Expected 
position and velocity performance for this simple low order propagation scheme is shown in Figure 14 for the period 
of radiation susceptibility in the EFT-1 trajectory. These plots depict the errors introduced solely by the SDR 
propagation scheme over various restart outage times At S DR • From this performance it should be clear that more 
error will inevitably be introduced when the orbital velocities are the highest simply because for the same 
propagation time, AtsDR, the vehicle will travel a further distance. In the period of radiation susceptibility this 
corresponds to times just after SEC02 and just prior to entry interface. Comparatively low errors will be introduced 
when the vehicle is near apogee. For the subsequent SDR analysis cases, a SDR outage time of 30 seconds is used 
as a bounding case for robustness testing, as this exceeds the worst case in all scenarios. These errors will show up 
in the Monte Carlo results by biasing the initial conditions with the magnitudes shown in Figure 14. 



Figure 14. Expected SDR Propagation Performance over the EFT-1 Trajectory Profile 


16 

American Institute of Aeronautics and Astronautics 


Ideally the position and velocity errors (A r SDR> Av SDR ) introduced after SDR would be far less than the expected 
uncertainty in the corresponding EKF filter states: 

II A r sdr II « 3 G riiJiK 

II A v SD r II « 3g V iJiK 

where the terms o TlJK >Ov I]K represent the cross channel EKF ICRF state uncertainties for position and velocity, 
respectively. Exceeding these conditions is risky because it can lead to smugness and instability in the restarting 
filter, however it will be shown that in the worst cases even substantially exceeding these bounds performance is not 
significantly affected. 



Figure 15. SEC02 30 Second SDR Inflight Restart Navigation (Position, Velocity) Performance 


The SEC02 SDR 30 second restart case is shown in Figure 15 with the expected initial condition errors in both 
position and velocity. Although the SDR propagation errors are large relative to the initial position and velocity 
uncertainty bounds o riJK > °v 1 j K errors quickly converge within the covariance bounds and performance at the end 
of the interval largely resembles the corresponding CCR restart case shown in Figure 9. 


ICRF Position Error ICRF Velocity Error 



Elapsed Time [s] Elapsed Time [sj 

Figure 16. CM/SM Separation 30 Second SDR Inflight Restart Navigation (Position, Velocity) Performance 


17 

American Institute of Aeronautics and Astronautics 


Attitude Error 


Clock Bias & Drift Errors 



Elapsed Time [$} Elapsed Time [s] 


Figure 17. CM/SM Separation 30 Second SDR Inflight Restart Navigation (Attitude, Clock Bias/Drift) Performance 


Similarly, a 30 second SDR cases is shown for at CM/SM separation in Figures 16 and 17. Although SDR 
propagation errors are relatively small at this point in the trajectory, combining this initial error with comparatively 
large delta-v and body rates due to the CM/SM separation itself at the same time are shown to introduce very large 
initial velocity errors after the restart event. Notice that despite the unhealthy filter initial conditions after several 
thousand seconds and greater numbers of GPS measurements these errors are cleaned up to reach performance 
levels comparable to the CCR restart cases shown in Figures 10 and 11. It is also important to note that the attitude 
errors in Figure 17 are largely unaffected by SDR as the VPU continues to propagate these states even through the 
CM/SM separation maneuver. Had the VPU not performed this functionality attitude errors would be shown to 
grow orders of magnitude higher in this case. 
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Figure 18. Entry Interface (El) 12 second SDR Inflight Restart Navigation (Attitude, Clock Bias/Drift) Performance 


Finally, a 12 second SDR restart performance at entry interface (El) is shown in Figure 18. In this case only a 
few seconds of GPS measurement processing were made available to the restarting FCM prior to hitting GPS 
blackout. SDR propagation errors are shown to influence the initial position and velocity states as expected, yet 
these errors are swamped by the errors that accumulate during the blackout period with no GPS and no cases are fail 
reacquisition of GPS measurements after blackout. 
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F. Forward Work 


In the previous sections the expected Navigation performance was quantified for a variety of conditions and 
restart types during the EFT-1 trajectory. While this analysis is far from complete and comprehensive it provides a 
starting point for future work to demonstrate Orion’s robustness to radiation induced upset events along the EFT-1 
trajectory. The first item that will further increase confidence in these results will include simulating multiple 
consecutive inflight restarts of various types and durations along the EFT-1 trajectory. In addition the cases shown 
need to be proven out with greater numbers of Monte Carlo runs to become more confident in their statistical 
significance. 500 run Monte Carlos are a good starting point but larger numbers of runs are likely needed to prove 
out the results. This type of analysis will show more robustness for the effects of cascaded filter initializations in a 
variety of conditions. In addition, these tests are already being performed in full hardware in the loop simulations 
with multiple FCMs, engineering equivalent avionics hardware. Some level of inflight restart testing will be 
performed with actual flight hardware prior to launch. 

Secondly, if there are any cases in which SDR propagation errors tend to cause filter divergence it is possible to 
increase the fidelity of the propagation scheme used for EFT-1. This propagation scheme was meant to be simple 
and lightweight so as not to needlessly overburden an initializing FCM, however if additional testing shows these 
assumptions to be in error additional steps to increase the fidelity of the propagator can be taken to mitigate this. It 
should be noted that for the cases shown in this paper 30 seconds of propagation is larger than the maximum bounds 
expected 

Additional EKF filter tuning may be required to better characterize the measurement and process noise levels in 
a time-correlated and sparse measurement environment such as that which will be experienced on EFT1. The EKF 
performance is predicated on the fact that measurement residuals will be well characterized by Gaussian random 
variables. As shown in earlier performance plots, this assumption is not always valid and additional steps may be 
required to mitigate these effects. A number of options including dynamic SV measurement masking as a function 
of elevation angle are being investigated. 

Finally, operational flight rules and procedures must be written for the EFT-1 mission that take into account 
contingency scenarios for inflight restart events. The ground will be monitoring for all such restart events as well as 
the quality of the onboard navigation solution. Ground rules will be written that allow for contingency operations to 
command updates to the onboard navigation state in the event the inflight restarts ultimately fail. These scenarios 
although not desirable will be the last resort to save the vehicle in catastrophic loss of vehicle scenarios. 


V. Conclusion 

The Orion inflight restart architecture has been designed to accommodate multiple restarts of the primary flight 
computers to increase the probability of EFT-1 mission success. The GN&C design for inflight restarts has been 
shown to be robust to a number of worst case bounding scenarios that can be envisioned for the EFT-1 mission. The 
concept of Cross Channel and Stored Data restarts are proved out through analysis and Monte Carlo dispersed 
simulation runs. Although these types of robustness runs are preliminary in nature, they provide initial confidence 
that inflight restarts will be successful if one or more are encountered on EFT-1. 


Appendix 

An appendix, if needed, should appear before the acknowledgements. 

Acknowledgments 


Lockheed Martin 

NASA 

Honeywell 


References 


19 

American Institute of Aeronautics and Astronautics 


The following pages are intended to provide examples of the different reference types, as used in the AIAA Style Guide. 
When using the Word version of this template to enter references, select the “references” style from the drop-down style menu to 
automatically format your references. If you are using a print or PDF version of this document, all references should be in 9-point 
font, with reference numbers inserted in superscript immediately before the corresponding reference. You are not required to 
indicate the type of reference; different types are shown here for illustrative purposes only. 


Periodicals 

Vatistas, G. H., Lin, S., and Kwok, C. K., “Reverse Flow Radius in Vortex Chambers,” AIAA Journal , Vol. 24, No. 11, 
1986, pp. 1872, 1873. 

2 Domheim, M. A., “Planetary Flight Surge Faces Budget Realities,” Aviation Week and Space Technology , Vol. 145, No. 24, 
9 Dec. 1996, pp. 44-46. 

3 Terster, W., “NASA Considers Switch to Delta 2,” Space News , Vol. 8, No. 2, 13-19 Jan. 1997, pp., 1,18. 

All of the preceding information is required. The journal issue number (“No. 1 1” in Ref. 1) is preferred, but the month (Nov.) 
can be substituted if the issue number is not available. Use the complete date for daily and weekly publications. Transactions 
follow the same style as other journals; if punctuation is necessary, use a colon to separate the transactions title from the journal 
title. 

Books 

4 Peyret, R., and Taylor, T. D., Computational Methods in Fluid Flow , 2 nd ed., Springer- Verlag, New York, 1983, Chaps. 7, 
14. 

5 Oates, G. C. (ed.), Aerothermodynamics of Gas Turbine and Rocket Propulsion, AIAA Education Series, AIAA, New York, 
1984, pp. 19, 136. 

6 Volpe, R., “Techniques for Collision Prevention, Impact Stability, and Force Control by Space Manipulators,” Teleoperation 
and Robotics in Space , edited by S. B. Skaar and C. F. Ruoff, Progress in Astronautics and Aeronautics, AIAA, Washington, DC, 
1994, pp. 175-212. 

Publisher, place, and date of publication are required for all books. No state or country is required for major cities: New 
York, London, Moscow, etc. A differentiation must always be made between Cambridge, MA, and Cambridge, England, UK. 
Note that series titles are in roman type. 

Proceedings 

Thompson, C. M., “Spacecraft Thermal Control, Design, and Operation,” AIAA Guidance, Navigation, and Control 
Conference , CP849, Vol. 1, AIAA, Washington, DC, 1989, pp. 103-115 
8 Chi, Y., (ed.), Fluid Mechanics Proceedings , SP-255, NASA, 1993. 

9 Morris, J. D. “Convective Heat Transfer in Radially Rotating Ducts,” Proceedings of the Annual Heat Transfer Conference , 
edited by B. Corbell, Vol. 1, Inst. Of Mechanical Engineering, New York, 1992, pp. 227-234. 

At a minimum, proceedings must have the same information as other book references: paper (chapter) and volume title, name 
and location of publisher, editor (if applicable), and pages or chapters cited. Do not include paper numbers in proceedings 
references, and delete the conference location so that it is not confused with the publisher’s location (which is mandatory, except 
for government agencies). Frequently, CP or SP numbers (Conference Proceedings or Symposium Proceedings numbers) are also 
given. These elements are not necessary, but when provided, their places should be as shown in the preceding examples. 

Reports, Theses, and Individual Papers 

10 Chapman, G. T., and Tobak, M., “Nonlinear Problems in Flight Dynamics,” NASA TM-85940, 1984. 
n Steger, J. L., Jr., Nietubicz, C. J., and Heavey, J. E., “A General Curvilinear Grid Generation Program for Projectile 
Configurations,” U.S. Army Ballistic Research Lab., Rept. ARBRL-MR03142, Aberdeen Proving Ground, MD, Oct. 1981. 

12 Tseng, K., “Nonlinear Green’s Function Method for Transonic Potential Flow,” Ph.D. Dissertation, Aeronautics and 
Astronautics Dept., Boston Univ., Cambridge, MA, 1983. 

Government agency reports do not require locations. For reports such as NASA TM-85940, neither insert nor delete dashes; 
leave them as provided by the author. Place of publication should be given, although it is not mandatory, for military and 
company reports. Always include a city and state for universities. Papers need only the name of the sponsor; neither the sponsor’s 
location nor the conference name and location are required. Do not confuse proceedings references with conference papers. 

Electronic Publications 

CD-ROM publications and regularly issued, dated electronic journals are permitted as references. Archived data sets also 
may be referenced as long as the material is openly accessible and the repository is committed to archiving the data indefinitely. 
References to electronic data available only from personal Web sites or commercial, academic, or government ones where there 
is no commitment to archiving the data are not permitted (see Private Communications and Web sites). 


20 

American Institute of Aeronautics and Astronautics 


13 Richard, J. C., and Fralick, G. C., “Use of Drag Probe in Supersonic Flow,” AIAA Meeting Papers on Disc [CD-ROM], 
Vol. 1, No. 2, AIAA, Reston, VA, 1996. 

14 Atkins, C. P., and Scantelbury, J. D., “The Activity Coefficient of Sodium Chloride in a Simulated Pore Solution 
Environment,” Journal of Corrosion Science and Engineering [online journal], Vol. 1, No. 1, Paper 2, URL: 
http://www.cp/umist.ac.uk/JCSE/voll/voll.html [cited 13 April 1998]. 

15 Vickers, A., “10-110 mm/hr Hypodermic Gravity Design A,” Rainfall Simulation Database [online database], URL: 
http://www.geog.le.ac.uk/bgrg/lab.htm [cited 15 March 1998]. 

Always include the citation date for online references. Break Web site addresses after punctuation, and do not hyphenate at 
line breaks. 

Computer Software 

16 TAPP, Thermochemical and Physical Properties, Software Package, Ver. 1.0, E. S. Microware, Hamilton, OH, 1992. 

Include a version number and the company name and location of software packages. 

Patents 

Patents appear infrequently. Be sure to include the patent number and date. 

17 Scherrer, R., Overholster, D., and Watson, K., Lockheed Corp., Burbank, CA, U.S. Patent Application for a “Vehicle,” 
Docket No. P-01-1532, filed 11 Feb. 1979. 

Private Communications and Web Sites 

References to private communications and personal Web site addresses are generally not permitted. Private communications 
can be defined as privately held unpublished letters or notes or conversations between an author and one or more individuals. 
They may be cited as references in some case studies, but only with permission of the AIAA staff. Depending on the 
circumstances, private communications and Web site addresses may be incorporated into the main text of a manuscript or may 
appear in footnotes. 

Unpublished Papers and Books 

Unpublished works can be used as references as long as they are being considered for publication or can be located by the 
reader (such as papers that are part of an archival collection). If a journal paper or a book is being considered for publication 
choose the format that reflects the status of the work (depending upon whether it has been accepted for publication): 

18 Doe, J., “Title of Paper,” Conference Name, Publisher’s name and location (submitted for publication) 

19 Doe, J., “Title of Paper,” Name of Journal (to be published). 

20 Doe, J., “Title of Chapter,” Name of Book, edited by... Publisher’s name and location (to be published). 

21 Doe, J., “Title of Work,” Name of Archive, Univ. (or organization) Name, City, State, Year (unpublished). 

Unpublished works in an archive must include the name of the archive and the name and location of the university or other 
organization where the archive is held. Also include any cataloging information that may be provided. Always query for an 
update if a work is about to be published. 


1 Inflight restart tech memo 

2 King, Odegard, Sequencing Paper AIAA 

3 TBD. Reference for CNC Thruster logic design memo 

4 TBD. EKF tech memos 

5 TBD. UDU formulation 

6 TBD. Reference to coupled attitude filter 

7 TBD. Reference to Holt, Zanetti AIAA 2013 paper. 


21 

American Institute of Aeronautics and Astronautics 


